1. Field of the Invention
The present invention relates to a workflow information generation unit, a method of generating workflow information, an image processing apparatus, a control program for generating workflow information, an image processing apparatus, and a storage medium for the control program, and more particularly, to maintaining consistency of workflow information.
2. Description of the Background Art
Utilization of digitized information (hereinafter referred to as electronic information or electronic data) has been expanding in many fields of business, industry, and the like. Digitized information can be generated by scanning documents with scanners, and may be output as printed images using printers or facsimile machines. As such, image processing apparatuses such as printers, facsimiles, and scanners are now indispensable for handling such digitized information.
Such image processing apparatuses may include functions such as image capture, image formation, and communication, so that these image processing apparatuses can be used as printers, facsimiles, scanners, and copiers. Moreover, some image processing apparatuses may be configured as multi-function peripherals by incorporating multiple functions of a printer, facsimile machine, scanner, and copier in one machine. In addition, file management systems like that described in JP-2008-97586-A are known, in which digitized documents are stored on a document management server or distributed to designated locations (e.g., destinations identified by computer addresses) and used.
In such file management systems, a given workflow may be developed to handle file information efficiently. For example, a workflow configured with a scanner function and an information processing function may be developed to efficiently store file information.
Typically, corporate users use such file management systems for managing file information generated in the course of business activities, wherein such file management systems are based on a workflow scheme. In general, corporations or companies each have their own in-house information infrastructure configured with a given e-mail system and a given network environment in which the file management system is used. Because each corporation or company uses its own unique in-house information infrastructure suited to its business activities, it is difficult to develop a file management system that can be adapted to every kind of network environment in advance.
Given that network environments may be different for different entities, workflow systems embodied as software development kits (SDK) and application programming interfaces (API) have been developed. Such programming tools as SDK and API enable users to configure workflow programs adapted to their own user-specific environment and needs.
In general, a workflow program may be configured with a plurality of processes in a given system environment. For example, when a workflow for storing file information is developed in a given system environment, such workflow may include a scanning process, a document formatting process, a mailing process, or the like, which needs to be executed to complete the workflow. When API is employed in such workflow, some of these processes may be executed using an externally-provided program, which may not be provided in the given system environment as a default program.
Further, by employing API, events which occur in a given system environment may be reported to an externally provided program, wherein the event may be a given operation such as counting the executed number of given process, for example. When such event occurs, the externally provided program may not be used to execute processes included in a given workflow but may instead execute a given procedure that the externally provided program is supposed to execute in view of a system condition or operations executed for the system.
For example, in the above-described file management system, the workflow may include a billing process, executed using an externally provided program, which may be used to charge a given fee to a user depending, for example, on volume of document information which is processed in such workflow. When a result of storage of digitized documents or file distribution processing is reported to an externally provided program using API, the externally provided program executes a billing process based on the volume of document information that is stored in a memory or the number of distribution addresses to which the file information is distributed.
With the above-described SDK, when an event occurs in a given workflow system, the event is reported to an externally provided program via API after a process related to the event is executed. Such event may be referred as an “after-event” because the event is reported to the externally provided program only after the process related to the event is actually executed. When the after-event is reported, the externally provided program can comprehend a system condition, status or the like. However, because the process related to the after-event has already occurred, the externally provided program to which the after-event has been reported cannot intervene in the operation of workflow system, despite the fact that the process related to the event may not be adequate for implementing the workflow system.
For example, assume a workflow scheme is configured with a plurality of processes executed using externally provided programs, in which a billing process is included to charge a fee for a given procedure. If one process is executed using one externally provided program and the billing process is executed for such one process, but thereafter another process is not correctly executed by another externally provided program because of an error, the workflow cannot be completed. In this case, although the workflow cannot be completed and the user cannot achieve his or her objective, he or she is still charged a fee by the billing process for such one process executed by the externally provided program.
Further, assume another case in which a user is to configure a workflow scheme by adding a process to the workflow, wherein the process may be executed by using an externally provided program. Such externally-provided program may be referred to as a “plug-in” or “plug-in program.” When a process is added to a workflow scheme, event information indicating addition of the process is reported to the externally provided program via API. In such a case, an addition to the workflow may be rejected by the plug-in program for some reason, for example, because of conditions placed on the number of licenses. If the workflow including such a rejection by the plug-in program is developed by a user, and the user implements such workflow, the plug-in program cannot be executed, thus necessitating reconfiguration of the workflow.
As such, if an event is reported to an externally provided program (or plug-in program) via API after an after-event occurs, the user is able to recognize that there is an error in the workflow scheme only after the workflow is implemented. Such error may be referred to as inconsistency of information included or related to a workflow, and as described above such information inconsistency included in a workflow cannot be detected immediately when the workflow scheme is developed. In addition, such information inconsistency may occur not only in a workflow system for file management system but also in SDK systems using an externally provided program via API.